With regard to aircraft systems, the invention is applicable notably to real time systems installed in an aircraft, also called avionic systems. The invention is thus applicable to flight management systems (FMS standing for “Flight Management System”), the repository of the “flight plan” for flights in non-segregated airspace.
Systems dedicated to flight plans, such as FMS systems, use as input the concept of “legs” according to the standardized terminology in the aeronautical field and contained in the AEEC ARINC424 international standard. The purpose of this international standard is to regulate the coding of the procedures issued by states, such as for example the departure or arrival procedures.
Legs are constituted by a termination (called termination legs in the ARINC standard) and a type characterizing the way of arriving at the termination (called Path in the ARINC standard). Terminations can be fixed, that is to say determined by their geographic coordinates on the terrestrial globe, the term “waypoints” or passing points then being used. They can also be floating, for example they can correspond to reaching an altitude or an interception with another leg. The paths can be of the orthodromic or loxodromic type. They can also characterize an arrival according to a fixed direction (heading), an arrival according to a fixed route (course), an arc of circle, or they can characterize a turn procedure. The ARINC 424 standard lists 23 types of legs. It also defines the possible combinations between legs, in pairs. In order to regulate the coding of the procedures, and to guarantee flyability according to international civil navigation criteria, the ARINC in fact only authorizes a limited set of combinations.
A flight plan is a succession of legs, that is to say a list of discrete elements. On the basis of this list, FMS systems construct a five-dimension trajectory, called a 5D trajectory, composed of a lateral trajectory and a vertical trajectory.
The lateral trajectory is the continuous “thread” which connects the legs of the flight plan to each other, whilst complying with:
the constraints of the “path” of each of the legs, defined by the ARINC424;
the certified envelope for the aircraft: limitations of the engine parameters, roll angles, etc.
the aircraft comfort: limitations of heading changes, of the roll speed, of engine thrust changes, etc.
The vertical trajectory represents the variation in altitude, speed, passing time and fuel over the course of time. It must comply with:
the vertical constraints (altitude, speed and time constraints);
the certified vertical flight envelope of the aircraft: flight ceiling altitude, maximum values of pitch, incidence, speeds, etc.
the aircraft comfort: limitations of incidences used, changes of speed, altitude variations.
The 5D trajectory resulting from the fusion of the lateral and vertical trajectories is complex to achieve because the two trajectories are strongly coupled:                The lateral trajectory needs data of the vertical trajectory in order to be constructed, in particular the lateral turn radiuses are a function of the aforesaid altitude and speed which will determine a maximum roll angle complying with a limit load factor. Some terminations of legs of the ARINC424 are in “altitude”, the leg terminating at the place where a target altitude is reached, the calculation of reaching the altitude resulting from the calculation of the vertical trajectory.        The vertical trajectory needs data of the lateral trajectory, in fact the length of the thread between two points which affects the altitude reached at the second point, starts and ends of turns and associated roll, affecting the lift of the aircraft, etc. . . .        The computers generally carry out iterations between the two trajectories until there is convergence. The calculations are complex and costly in computing time.        
Third party trajectory systems do not operate on flight plan data but directly on data of the trajectory. Taking account of their nature:
The surveillance systems (terrain, traffic, meteorological) calculate a lateral or vertical or 5D trajectory by definition; there is in fact no reason for them to depend on the linking of airspace legs, the elements to be avoided having any geometry and location whatsoever. These systems do not include an ARINC 424 navigation database;
The relative navigation systems calculate a trajectory in order to be locked onto a target (aircraft in general); they determine, for example, a vertical trajectory for changing from a given altitude to a target altitude, whilst remaining separated by a limit distance from the aircraft which precede them and whose altitude they intersect;
Mission or advanced guidance systems carry out patterns of trajectories, also called “patterns”, of missions having their own geometry, almost systematically different from the possibilities offered by ARINC424. The “patterns” for following buoys at sea, for refueling, snail or spiral, ladder or flower search patterns and drop patterns are trajectories that have nothing to do with ARINC424. Moreover they have the characteristic of not being geometrically fixed in time but are evolutive, in fact the “pattern” of a refueled aircraft must follow the refueling aircraft, the drop point of a drop “pattern” evolves with the wind, the load having to fall onto the same place in the ground, the SAR search pattern evolves in real time with what is detected by the sensors, interception patterns of fighters in the context of airborne police for example. These trajectories are said to be dynamic.
As the third party systems evolve in the different contexts of civil, commercial or other flights, the required capabilities of the aircraft (constraints, envelopes, comfort) are different and these systems therefore produce trajectories according to different computation modes.
One problem whose solution is sought is that of reconciling the systems dedicated to the flight plans and the third party trajectory systems in order to give those operating them (crews, ground operators) a consistent overall view of a mission composed of sections of trajectories coming from several computers. In particular, it is sought to:
make it possible to calculate passing time and fuel predictions over the whole of the flight;
avoid the tedious operations of manually connecting the sections of trajectory from the different computers by the pilot, by an automatic and optimized connection of the sections;
have the capability of processing any type of section notably relative to the flight plans, 2D trajectories, 2D+V trajectories, 3D trajectories, 3D+V trajectories, trajectories with or without transitions, within the same method;
decoupling tactical problems (notably display for the pilot, sending the trajectory to the control systems of the automatic pilot type) from strategic problems (notably calculations of time and fuel predictions);
have the capability to transcribe the various sections of trajectory of one system by that of another system, in particular to have the capability of substituting, in the flight plan of the flight plan dedicated system, a section coming from a third party system, for example a meteorological surveillance system, which replaces the current flight plan by a meteorological avoidance trajectory and which after a certain time, taking the meteorological evolution into account, reduces its avoidance, making it necessary to return to the initial flight plan over the cleared area.
In current systems, on recent civil or transport aircraft, the management of the flight plan (resulting from the ARINC 424 legs) is generally separate from the management of mission trajectories, in particular:
the aircraft is either in a “flight plan” mode involving the calculation of the trajectory coming from that flight plan, the calculation of the deviations for guiding the aircraft on the specific trajectory and the display of the trajectory;
or the aircraft is in a “mission” mode: the term “mission” is understood to be any alteration of the flight plan by a trajectory such as an avoidance (for meteorological, traffic, relief or threat reasons for example) or a specific “pattern” (of the SAR, drop, refueling or terrain following type for example); the equipment originating the trajectory then sending its instructions directly to the guidance system or to the pilot so that he can follow them;
the systems are therefore segregated, both for the calculations of instruction trajectories and for the guidance of the aircraft, the selection of the navigation sensors, the display to the crew and the communication with the other ground and onboard systems.
There are aircraft in which a third party system, such as a mission system, is connected to the system dedicated to the flight plan (the FMS for example), and transmits to the latter a “mission” flight plan constituted by waypoints in the standardized format of FMS systems, notably conforming to the ARINC 702A and ARINC 424 standards. The mission system does not directly transmit trajectory to the FMS, the latter not being designed to manage an external trajectory; the mission system must therefore generate a format compatible with a flight plan in order to interface with the FMS.
A document FR 2 984 538 A discloses a solution for managing a mission not using the FMS computer, a secondary computer routing the instructions of the FMS and the instructions of the mission system to the guidance system as a function of the type of operation: flight management in non-segregated space or mission in segregated space. This document describes a system with segregated computers without concatenation of the trajectory.
A document EP 2 459 963 A describes an architecture comprising a mission system and a civil system, both of them for the navigation and the communications, in different partitions, making it possible to update the systems independently without recertifying the whole assembly. An FMS controls the civil “navigation and communications” partitions. A mission system controls the tactical “navigation and communications” partitions. It is also a system in the context of segregated computers without concatenation of the trajectory.
The solutions of the prior art, and notably the above ones, are not satisfactory. In known solutions, one dedicated system processes its flight plan, for example the FMS, whilst another system processes its section of trajectory, for example a tactical mission system or an onboard surveillance system. The two systems do not communicate, forcing the crew to make the connections mentally and to switch navigation, communication and guidance modes manually when they change from one section to the other. These solutions therefore require lengthy operations, often on several systems to be coordinated.
In other known solutions, the system dedicated to the flight plan requires third party systems to format their sections of trajectory in order to be able to interface with it. Numerous disadvantages result from this:
the third party systems must have program codes for carrying out the transcription according to the rules of the flight plan system which are often complex, for example in order to generate an FMS flight plan in the ARINC 424 format. The cost is high for the development of these functions which moreover introduce a dependence of the third party system with respect to the capabilities of the system dedicated to the flight plan. This also restricts interchangeability;
the third party systems can create data that will not be accepted by the system dedicated to the flight plan for memory capacity reasons, the number of waypoints for example usually being fixed at 100 or 250 depending on the versions of the FMS systems. This notably limits the operational capability of the function to be carried out if the third party system has to constrain its trajectory so that it is compatible with the interfaces and computing capabilities of the system dedicated to the flight plan;
there is duplication of information when the third party system generates a trajectory to be inserted in a flight plan, this redundancy moreover sometimes being inconsistent because the construction hypotheses of the two systems are not strictly identical to each other;
the trajectory sections can be dynamic, for example in the case of moving buoys for a SAR (Search And Rescue) computer, requiring periodic transmissions of formatted sections not compatible with the CPU performance of the system dedicated to the flight plan. The updating of trajectory at a rate greater than 1 Hz (1 trajectory per second) is impossible to integrate with the present day onboard technologies and hardware of systems dedicated to the flight plan;
the systems dedicated to the flight plan constrain the construction of the lateral and vertical trajectory in order to ensure its “flyability”. The geometry is produced in such a way that the instructions sent to the guidance system, constituted by the automatic pilot or by a joystick, to be used there for control are by nature in the flight envelope of the system in question;
the systems dedicated to the flight plan do not have substitution functions allowing the temporary replacement of a part of the portion of flight plan by a trajectory section;
significant excess costs are inescapable for the system dedicated to the flight plan to be able to process the features of the sections from the third party systems, for example the sections that have greater dynamics than the system dedicated to the flight plan can process, such as for example a large roll angle or transitions specific to the third party system which do not exist in a conventional system dedicated to the flight plan.